Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Begin implementation of wasi-http #5929

Merged
merged 53 commits into from
Apr 5, 2023

Conversation

brendandburns
Copy link
Contributor

@brendandburns brendandburns commented Mar 4, 2023

Initial draft, working, but with limitations.

Known issues:

  • Outbound requests only, inbound HTTP serving is not supported
  • Body for requests is not supported
  • Request options (e.g. timeout values) are not supported.
  • There are panics all over the place if you pass in bad pointers or unexpected values.

@brendandburns brendandburns force-pushed the wasi_http branch 3 times, most recently from f746c98 to 9506b57 Compare March 13, 2023 03:57
@brendandburns brendandburns changed the title [WIP] Begin implementation of wasi-http Begin implementation of wasi-http Mar 13, 2023
@brendandburns
Copy link
Contributor Author

@pchickey I think this is ready for an initial high-level review.

Everything is implemented in terms of the wit-bindgen interfaces, and then an adapter is introduced which maps from the wit-bindgen to the current wasmtime::Linker implementation.

This means that it is very forward compatible with the component model linker going forward.

If you can take a quick look at the rough layout and see if this is on the path to merging that would be great.

After we get the rough layout right, we can move on to a more detailed review.

Thanks!

@brendandburns
Copy link
Contributor Author

There's also a pretty extensive example that can be used to test this implementation in crates/wasi-http/example

Copy link
Contributor

@pchickey pchickey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exciting! Here's my first pass of feedback

crates/wasi-http/src/component_impl.rs Outdated Show resolved Hide resolved
crates/wasi-http/src/component_impl.rs Outdated Show resolved Hide resolved
crates/wasi-http/src/component_impl.rs Outdated Show resolved Hide resolved
crates/wasi-http/src/component_impl.rs Outdated Show resolved Hide resolved
crates/wasi-http/Cargo.toml Outdated Show resolved Hide resolved
crates/wasi-http/Cargo.toml Outdated Show resolved Hide resolved
crates/wasi-http/Cargo.toml Outdated Show resolved Hide resolved
crates/wasi-http/Cargo.toml Outdated Show resolved Hide resolved
crates/wasi-http/Cargo.toml Outdated Show resolved Hide resolved
},
)?;
linker.func_wrap(
"types",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit surprised all these functions landed in the types module name, that may be something we have to look into...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, surprised me to, seems like some sort of aliasing in wit-bindgen

@brendandburns
Copy link
Contributor Author

brendandburns commented Mar 14, 2023

Comments addressed except the macro vs fn comment because I'm not clear how to resolve the compile error.

Please take another look.

crate::types::Method::Options => Method::OPTIONS,
crate::types::Method::Trace => Method::TRACE,
crate::types::Method::Patch => Method::PATCH,
_ => return Err(anyhow::anyhow!("unknown method!")),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
_ => return Err(anyhow::anyhow!("unknown method!")),
_ => return bail!("unknown method!"),

crates/wasi-http/src/lib.rs Outdated Show resolved Hide resolved
@brendandburns
Copy link
Contributor Author

Ok, this was switched to hyper. I'm not sure it really saved you very many dependencies, but if there are other ways to reduce the dependency count, let me know. Hyper doesn't implement TLS, so I had to pull in hyper_native_tls

I think this is ready to go, let me know if there is a good way to add tests, it seems the other modules don't really have tests.

@brendandburns
Copy link
Contributor Author

@pchickey

Ok, I implemented timeouts. I think that the client side implementation is now basically feature complete. Ready for a more detailed review whenever you have time.

Thanks!

@brendandburns
Copy link
Contributor Author

Oh, and I plan on starting the server side implementation in a different branch.

Copy link
Contributor

@eduardomourar eduardomourar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have tested this with a real-life Wasm module and it works as expected.

crates/wasi-http/Cargo.toml Outdated Show resolved Hide resolved
crates/wasi-http/Cargo.toml Outdated Show resolved Hide resolved
brendandburns and others added 2 commits March 23, 2023 16:48
Co-authored-by: Eduardo de Moura Rodrigues <16357187+eduardomourar@users.noreply.github.com>
Co-authored-by: Eduardo de Moura Rodrigues <16357187+eduardomourar@users.noreply.github.com>
Copy link
Member

@Mossaka Mossaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mostly lgtm!

crates/wasi-http/src/streams_impl.rs Outdated Show resolved Hide resolved
@brendandburns
Copy link
Contributor Author

brendandburns commented Apr 5, 2023

@pchickey I conditionalized tls to disable it on riscv64gc

I tried the prtest:full thing but it didn't seem to work for me, maybe I did it wrong...

Anyhow, perhaps we can give this another try? If there's a way for me to trigger the full test runs w/o you adding it to the merge queue, let me know what I need to change in my commit message.

Turns out the gh status was just cached and lagging, prtest:full appears to work correctly.

Turns out that ring doesn't work on s390x either, so I conditionalized that also. We may want to investigate how we can go back to native SSL, but that's for another PR...

Fix formatting, also disable tls on s390x
@brendandburns
Copy link
Contributor Author

cc @pchickey

Ok, next issue hit:

The wasmtime::component::bindgen! macro expects a folder named wit in the same directory as the Cargo.toml

The challenge is that if we want to pull the wasi-http repository in as a git submodule, then the directory structure is messed up, so I used a symbolic link to link wit -> wasi-http/wit but it looks like those symbolic links don't work properly for Windows.

I can get rid of the git submodule, and just check in the wit files directly into this repo, it will make it a little more annoying to keep the wit files in-sync but it's do-able.

Let me know what you think.

`

@brendandburns
Copy link
Contributor Author

It looks like maybe setting git config --global core.symlinks true in our builds would fix things? But I'm not certain where those builds are configured, I can't seem to find them in main.yml

@cfallin
Copy link
Member

cfallin commented Apr 5, 2023

Is it possible to modify the macro to have a configurable path? I think we'd probably prefer that over most any directory-structure or build-time hack (symlinks, copying files, or the like).

@eduardomourar
Copy link
Contributor

I believe the macro does accept a path property and you can check it here: https://github.com/bytecodealliance/wasmtime/blob/main/crates/component-macro/tests/codegen.rs

@brendandburns
Copy link
Contributor Author

@eduardomourar thanks for the pointer (I don't think that's documented anywhere :() I updated this to use path and I removed the symlink.

crosses fingers

Add a path parameter to wit-bindgen, remove symlink.
@brendandburns brendandburns force-pushed the wasi_http branch 4 times, most recently from 9f18454 to 85a2e52 Compare April 5, 2023 17:10
Fix tests for places where SSL isn't supported.
@brendandburns
Copy link
Contributor Author

@pchickey This passed complete CI, but it needed a rebase. I'm pretty sure that it will pass the merge queue this time.

Thanks for the patience!

@pchickey pchickey enabled auto-merge April 5, 2023 20:00
@pchickey pchickey added this pull request to the merge queue Apr 5, 2023
Merged via the queue into bytecodealliance:main with commit 2d34dbe Apr 5, 2023
@brendandburns
Copy link
Contributor Author

🥂 🎊 🥂

Thanks for the patience here, I'll send in some follow-on PRs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants